Several issues with this method:
I always find it very confusing two mix up declaration order, object comes as an argument and it's should be the focus of this function but instead is used at the very end for the first time. buildFormData is complex enough to be declared elsewhere, in fact it can be extracted without refactoring since it does not depend on objectToFormData.

The fact that an empty object is being populated from scratch suggests to me a reduce could be used here, ideally:

formData = body.reduce(buildFormData, {})

Recurrence is nice provided the method signature doesn't change but here both data and parentKey generate control couples which IMHO means it should be split (at least) in two. On top of that formData is empty during the first iteration colliding with the actual method signature:

Record<string, never>
// vs
Record<string, boolean | number | string>

There is not one test for this method. I've spent a fair amount of time looking at it and still cannot get the grasp of it so it will be hard to maintain. Considering its purpose is pretty straightforward I strongly suggest it be refactored. I'm working on an alternative right now, I really rather sacrifice verbosity for readability.

I think buildFormData is OK to be inside objectToFormData. Otherwise the only thing objectToFormData would do is to call buildFormData, no need to create a new function for that. In any case, what I would do is remove objectToFormData and call buildFormData({}, body) directly from transformReportRequestBody.

The fact that an empty object is being populated from scratch suggests to me a reduce could be used here

That's what I thought initially, but the problem is that we do need to traverse the whole object tree, so I am not sure that reduce would be that helpful (or easy to implement).

I'll address the rest of the comments later.

I always find it very confusing two mix up declaration order, object comes as an argument and it's should be the focus of this function but instead is used at the very end for the first time.

Well, the only reason why it is used in the end is because buildFormData is declared inside. I can extract it from there, no problem. It's just that I think thought of objectToFormData as a function that does everything, I think it's pretty useless if we just keep the last 3 lines (basically, I agree with what @jlledom says, except I don't think we need to call buildFormData({}, body) directly from transformReportRequestBody.
Anyway, I will see if I can make it more readable.

buildFormData is complex enough to be declared elsewhere, in fact it can be extracted without refactoring since it does not depend on objectToFormData.

But do we need to have an exported function somewhere else (where?) if we know it is not going to be used by anything rather than this function? To me it makes more sense to keep the things together in this case, this will avoid the need to jump around multiple files/lines in the same file to understand what the function does.

On top of that formData is empty during the first iteration colliding with the actual method signature: [...]

Doesn't Record<string, boolean | number | string> accept {} ?

There is not one test for this method.

Fair enough, although the test would be for objectToFormData as it's the one that is exported.

I've spent a fair amount of time looking at it and still cannot get the grasp of it so it will be hard to maintain.

What's confusing about it? What would you suggest?

I tried to give it a spin, but I did not manage to get rid of recursion in favor of reduce and friends.

I don't think it makes sense to waste more time on this. It's a very specific case, and it currently works for the issue it is meant to solve.

If you have an alternative implementation - please share 😉

I won't insist, I lost this battle. One last war cry in favor of SRP though: a function that does everything is wrong. A function must do one and only one thing. And it's OK to have a 1 or 2 line function as long as it complies with SRP. It makes it more readable and more maintainable.

LOL, "function that does everything" was probably an overstatement 😅 IMO objectToFormData actually does 1 thing (transform one object format to another), but it's self-contained, so you don't need to jump around the code to understand what it does.

But well, I understand your point also. Does this look better to you? a7a2e45

I think buildFormData is OK to be inside objectToFormData. Otherwise the only thing objectToFormData would do is to call buildFormData, no need to create a new function for that. In any case, what I would do is remove objectToFormData and call buildFormData({}, body) directly from transformReportRequestBody.